Next up for my speed run of iOS 26 first draft redesigns is the main Home Screen of Pedometer++.

This one proved pretty straightforward, at least to get to the solid draft stage.

The initial step was to adopt the new Tab Bar design. Pedometer++ had previously used a completely custom tab bar control, which caused all manner of complexity and trouble. So this seems like the opportune time to switch back to the system one, especially since it is so glassy and a hallmark of the new look.

Similarly the top navigation bar buttons are adapted to the new button shapes and looks.

Note that the tab bar tint being blue is just an artifact of the way SwiftUI Previews work, in the app it is actually green.

Right away this is looking pretty much at home in the new design language. But there is something which bothers me a bit. All the empty white space feels a bit expansive in a less useful way. One of the features of the old design was that the top bar would tint based on your current day’s goal performance. I try to have visual clues and encouragements in the UI to help motivate you to reach your step goal.

So let’s try making the whole background rather than white, a tinted color matching the current goal state.

Here it is way overdone on purpose to show what I mean.

Or here it is adapted to each of the red, orange, green states at a more appropriate level of strength. I think that overall works better. Especially for the glassy controls, they seem to work really well against something which has some color. On completely white they drop a bit of their distinctiveness and are harder to quickly identify as buttons.

Lastly I just need to clean up the backgrounds of a few of the views which were previously assuming a white background and so now look a bit weird (like in the streak length marker label). Also, I think the title text needs to be a bit bigger to better balance with the button sizes.

That’s pretty solid. I like it, it feels ‘new’ but not in a way which I think will cause confusion or complaint. This root screen is the heart of Pedometer++, and has been very similar for nearly 10 years now. I want to be very conservative with updating it, so as not to cause customer frustration.

Here is a before and after:

Yesterday’s re-design involved updating the “Start Workout” screen, which I chose as one of the core screens of the app. Today I’m going to walk through redesigning another of more pivotal areas of the app, maps!

Pedometer++ has a number of mapping based features for planning and reviewing your walks, hikes or runs. Within Apple’s own iOS 26 apps, I’d say that Apple Maps is one of the prettiest implementations of the new design. Conveniently it also includes several of the kinds of features which Pedometer++ has to find a design for.

This is a screen which actually neatly falls into a clear separation between “content” and “controls”. In the “Start Workout” screen this was much squishier, but here we have the map and its annotations and then things which either edit or report on that contents. This is a perfect spot for concentric glassy elements overlaying the content.

Here is my starting point:

This design feels very constrained in the perspective of the new language, the map is squished between the two white bars and overall this feels like it creates an unstable tension.

So the very first thing I need to do is to get that map going edge to edge.

That already feels much fresher, but the text based top buttons feel a bit heavy and distracting. So let’s swap those out for some of the newly defined Standard system icons.

Often the “primary action” is given the prominent button style. So let’s try that for now.

Now let’s put the elevation graph and route stats panel back as a floating glass sheet. The proper API to round this sheet (.containerConcentric) doesn’t appear to be in Beta 2, so I’m just fudging this for now with some hard coded corners radii. The overall effect is pretty good, just enough of the map shines through to give a pretty effect but still very legible.

I think I’m gonna drop the toggle for distance vs time scale on the chart. The difference is way too subtle in most situations to be useful and I think it just creates confusion overall. That leads to a much cleaner looking chart.

Next to start putting back in the buttons which control the route editing. First up the search for location button. This is used to allow the user to jump to a named place rather than having to swipe around the map.

Then the route editing controls for removing points or switching between snapping to paths or straight line plotting. To start with I just plopped the current buttons in their with a .glass button style.

That is obviously way too wordy and doesn’t really fit with the sleek UI I’m going for. So I’m gonna make two changes. I’m gonna drop the “Remove All” option from this primary editing UI. It is rarely used and dangerous so likely best put in the “Settings” area for the route. Then I’m switching over to simple icons for the buttons.

That is visually a lot better but I think it makes it much more confusing about what the snap to path vs straight line plotter button does. So I think I’m gonna put a status area above the info sheet. This also can contain transient messages when it is doing route processing or similar.

I think the info sheet could benefit from a bit of visual distinction between the elevation graph and the route information. They are related but look a bit too smushed together right now.

I think I might also try pulling down the route name into the button sheet and the settings button too.

That’s the right idea but the settings button isn’t right there. It should likely be next to the route name area.

That is getting pretty close but I think the scaling isn’t right. So let’s make the button a bit bigger and move the route name out of the header.

I like that but I think the “Edit Route” text is kinda redundant and makes the map feel a bit squished again. So maybe let’s leave it open so that the map can fade gently to the top bar.

Getting pretty close to a first draft, but the more I look at it I don’t like the way the top right button is the only filled in button. While it is the ‘primary’ action it feels off balance to me. So let’s go back to a simple tinted symbol.

Much better. I feel pretty good about that as the starting point for now. That feels very ‘iOS 26’-ey to my eye. The metrics are still a bit off, and I think the graph styling feels a bit disconnected but this is a good place to stop for now and move on to the next screen.

Yesterday afternoon I submitted my last major pre-iOS 26 update (which feels very good to be out the door). So I am now able to turn my attention more fully to iOS 26 updates.

I’m starting by focusing exclusively on the design update portion of my iOS 26 work. While there are a variety of other functional changes I need to make, what is most important right now is to build a basic design so that I can start living with it and see how it feels in practice.

Finding Inspirations

The overall complexity of the design changes are much simpler in Pedometer++, and so that’s where I’m going to start (rather than Widgetsmith). Then within Pedometer++ I need to decide where am I going to begin work.

I need to establish the visual language that I’m going to carry through the app. The new Design Language of iOS 26 is not wholly prescriptive, it leaves large room for individual interpretation and places for me to put my own spin on things.

So I took a look at Pedometer++’s screens and picked out a handful of “core” screens which I think if I get right will serve as a strong foundation to then apply to all the other parts of the app.

The first of these core screens is the “Start Workout” screen:

I’m starting here because it includes a number of the custom controls I’ve built for Pedometer++ and also because it is a good example of a “configurator” screen.

My design process while still trying to learn the new design language is that once I pick the screen I want to work on then I will scour the Apple provided apps for examples of things which hold similar components. I’m looking for inspiration and examples of the numerous small details which make up a consistent design. Apple has a clear head-start on my own understanding and so I’m trying to shortcut as many pitfalls as possible.

I put all these screenshots into an “Inspo” folder and regularly scan through them while I’m mulling over a design detail to see if there are components I can draw from. In this case I found that the “Create Reminder” screen is probably the closest thing to my “Start Workout” screen, with the “New Event” screen a close second.

Iteration

The first things I need to do is to change the bottom “Start Workout” button from a translucent sheet to a glassy button with an edge blur along the bottom. I think this fits well with the general ideas of placing important controls along the bottom edge and using glass to indicate a navigation/structural control.

Next the headers in the sections are way too big and heavy, so these are toned down.

My custom segmented control looks out of place now. I could either change it to being a capsule shape (which generally seems to be the default control shape now), or I could try using the default system segmented control picker.

That feels more at home in the design, but I also find having several of these next to each other visually very busy. So instead I’m gonna try using the menu based picker instead.

For a user choice which likely doesn’t change very often this feels much cleaner and clearer. This control will default to your most recently used option so most users will likely only change it once. I like that much better, so will also apply that to the Workout Goal setting.

Next up are the shadowed, round-rect buttons I was using before. I start off by making them capsule shapes and giving them a flat appearance.

I think the sections being colored and the background being white doesn’t look quite right so let’s flip that around.

Much cleaner, but now the inline buttons look way too strong and have the same visual prominence of the main “Start Workout” button. So let’s tone those down by making them use the secondary color for their background, keeping the color in the text instead.

Much better. The contrast in the buttons still needs some work, but overall the structure and general “feel” seems pretty good now.

Here is the before and after for comparison.

This picks up a lot of the general design cues of the “Add Reminder” page but in a way which (hopefully) feels familiar to someone who was coming from the iOS 18 version.

Next up…maps.

This time of year there is always a murmur amongst app developers, blinded by shininess of the new iOS, to consider whether to drop support for older versions of iOS and jump fully to requiring the new stuff. Doing so can make your life a whole lot simpler and your code a lot cleaner.

There are two major considerations to make before doing this: one more obvious, the other more subtle.

Existing Users

If you drop support for older versions of iOS, existing users who haven’t updated but who have the app already downloaded will continue on as though nothing happened. Should they delete and want to re-download the app they can do so from their App Store history. Generally speaking their only impact is that they won’t get any new updates, which could include bug fixes or improvements which would benefit them.

iOS generally has really good adoption of new versions. With the vast majority of devices which can update running it within a few months of release.

Looking at Widgetsmith today I see that 86.5% of my users are on iOS 18.

Which means that 9 months in, if I went iOS 18+ only today I would be locking around 13% of my users onto the current version (with a reasonable expectation that more would subsequently update to either iOS).

New Users

Things get a bit more complicated when considering the impact on the future growth of the app. While existing users will continue to be offered the last compatible version of your app by the App Store, new users will not be able to acquire it. If they open the App Store they will be told this app is not compatible with their device.

While I would, in some ways, prefer it if Apple instead showed them the last compatible version for download, I can understand how that would cause confusion. But as an app developer it means that any time I increase my required iOS version I’m also reducing my prospects for future growth.

When I look at my current new downloads by platform version I see a distribution broadly similar to the one in for usage but skewed slightly newer.

For example, if I went iOS 18 only today I’d exclude around 9% of my current new users from acquiring the app. Which from my perspective is kinda huge. If I could do something which boosted my downloads by 9% I’d be delighted.

The story gets even more complicated for newly released versions of iOS, the initial adoption of iOS versions is very metered (I imagine while Apple ensures all is smooth and well with the update). So if you were to require the latest version on launch day you’d dramatically reduce your audience for a while, until adoption broadened out.

Here is the distribution of new downloads by platform version for Widgetsmith for the iOS 18 release cycle:

While I saw an initial surge of downloads on iOS 18 (peaking around 60% on launch weekend), it then quickly retreated to 40% and then slowly increased from there. There is a big jump (to about 80%) at the end of November when Apple enabled broad automatic updates.

Every app is different but this gives a general idea of how you’ll reduce your new downloads by requiring newer versions.

 This data can be found for any app in App Analytics > Metrics > New Downloads (viewed by Platform Version)

Thoughts

My general approach is to only increase my requirement once the new download rate drops to a percent or so. The technical and practical benefits become justifiable to me once I’m only loosing that many users. Otherwise it feels like I’m doing something to make my technical life a bit easier but my business meaningfully worse. That tradeoff will vary by app and business goals, but generally I consider it wise to take a cautious approach whenever possible.

I was fortunate enough to get one of the Design Labs late last week, which meant that I spent Friday morning frantically doing as many first-pass updates to the new design as I could. I then was able to discuss many of them during the lab and learned a bunch.

Something in particular which I heard a few times was that I was overusing Liquid Glass. Which I suppose makes sense, it is the literally shiny new thing. Looking back at these early redesigns, I was mostly just rounding everything and adding Liquid Glass to all interactive elements.

Here is a basic example of this in action:

For the Route list, I just added the .glass button style to the share and delete buttons. When you’d tap on them, they’d then get the cool lift-up fluid effect.

Something my design lab consultant said, which was really clarifying for me, was that Liquid Glass should generally be used to highlight content underneath the button. So if that content is plain/flat, then it is likely not appropriate. In this case, if the button was over the map preview, then it might be appropriate, but since the whole section is tappable, then I’d have two levels of interactivity, which is generally not great.

In this case after the lab I took another attempt at redesigning the route chooser rows and ended up with this:

This isn’t definitely done yet but feels much better, and more in keeping with the general look of the new design language. I still need to do work on the overall layout here, but moving the buttons into the row’s selection sheet feels much better and gives me much more flexibility about how I layout this page.

As will likely often be the case for posts like this, I can finish with the relevant page in the HIG.

Be careful how much you use the new shiny new Liquid Glass effect. A good new design isn’t one which uses that everywhere; it is one which uses it to great effect.